Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

_{Comment @coderabbitai help to get the list of available commands.}

LLxprt PR Review – PR #2634

Issue Alignment

Implements the /assign workflow from #2630: exact-match /assign comment gate, eligibility via merged PR or prior assignment (backfill file, current assignments, or per-login history label), 3-issue cap, auto-assigned label, sticky bot feedback, and a daily stale cleanup that unassigns auto-assigned issues after 14 days with no linked PR activity while exempting acoliver. Evidence: .github/workflows/assign.yml, .github/workflows/assign-stale-cleanup.yml, .github/scripts/assign-issue.sh, .github/scripts/unassign-stale-issues.sh, .github/scripts/record-assignment-history.sh, and CONTRIBUTING.md updates.

Side Effects

• Adds a scheduled workflow and 4 new scripts under .github/.
• Creates per-user labels (asnhist--LOGIN) in the repository; bounded by actual assignees but could accumulate over time.
• Uses github.token and issues: write; stale cleanup restricts scheduled runs to vybestack/llxprt-code.
• record-assignment-history.sh runs on issues:assigned; bot-triggered assignments are also recorded directly from assign-issue.sh to avoid recursion gaps.

Code Quality

• Strong fail-closed posture: pre/post mutation re-reads, targeted POST/DELETE mutations, verified rollback, and lifecycle traps.
• Winner election uses timeline event position ordering and handles concurrent bot contenders; stale cleanup includes provenance validation, pre-delete revalidation, and co-assignee preservation.
• Main risk is complexity in assign-issue.sh/unassign-stale-issues.sh; however, the scripts are well-structured with defensive checks and clear error paths.

Tests and Coverage

• Coverage impact: increase.
• Adds behavioral tests executing real bash scripts against a stateful fake gh adapter (scripts/tests/fake-gh.py), plus workflow YAML/contract tests.
• Tests cover eligibility, cap, sticky feedback, exact-match gating, stale cleanup, pagination, linked PR detection, exemptions, and failure preservation.
• Note: I could not execute tests in this environment (npm run test fails due to missing vitest/bun; PR author reports bunx vitest run --config scripts/tests/vitest.config.ts scripts/tests/assign-workflow.test.js passed 11/11).

Verdict

Ready — implementation matches issue requirements, side effects are bounded and documented, code quality is high with defensive concurrency handling, and test coverage materially increases with real-behavior assertions rather than mock theater.

OpenCodeReview — PR #2634

• Reviewed head SHA: f4ebf79a11aa1190300f8252b71e3a804981a34c
• Merge base: a20e30f14609ceca070fed5140510bbb36daee28
• OCR version: open-code-review v1.7.9 (a32f852) linux/amd64 built at: 2026-07-14T03:41:57Z https://github.com/alibaba/open-code-review
• Phase: review
• Exit code: 0
• Run: https://github.com/vybestack/llxprt-code/actions/runs/30075489627
• 41 finding(s) (39 posted inline).
• Artifacts: ocr-review-output contains raw JSON, stdout, stderr, preview, phase, and exit-code diagnostics.

Findings without a resolvable position

• scripts/tests/assign-remediation5.test.js: > The comment says the side_effect fires on the 'pre-delete assignee GET', but the configured endpoint is 'repos/test/repo/issues/42' (an issue GET, not an assignee GET). Please update the comment to accurately describe the trigger so future maintainers are not misled about which API call drives the race.
• scripts/tests/assign-remediation8.test.js: > The signal test uses a fixed 500-iteration × 10ms polling window (5s total). Under heavy CI load or slow filesystems, the hook file may not appear within this window, causing flaky failures. Consider either increasing the timeout or making it configurable via an environment variable (e.g., ASSIGN_SIGNAL_TIMEOUT_MS).

@Ayush7614 run shellcheck

@CodeRabbit is the shell necessary in here or could this be done entirely in yaml?

#!/bin/bash
set -euo pipefail

printf '%s\n' '== Candidate files =='
fd -a '^(assign\.yml|assign-issue\.sh|assign-stale-cleanup\.yml|unassign-stale-issues\.sh|assign-workflow\.test\.js)$' . \
  -E node_modules -E dist -E build

printf '%s\n' '== Workflow outlines =='
for f in $(fd -a '^(assign\.yml|assign-stale-cleanup\.yml)$' . -E node_modules -E dist -E build); do
  echo "--- $f"
  nl -ba "$f"
done

printf '%s\n' '== Script function outlines =='
for f in $(fd -a '^(assign-issue\.sh|unassign-stale-issues\.sh)$' . -E node_modules -E dist -E build); do
  echo "--- $f"
  rg -n '^(#!/|[[:alpha:]_][[:alnum:]_]*\(\)|[[:alpha:]_][[:alnum:]_]*\(\s*\{)|\b(gh|jq|curl)\b|case |if |while |for )' "$f" || true
done

#!/bin/bash
set -euo pipefail

printf '%s\n' '== Repository change summary =='
git status --short
git diff --name-status HEAD~1..HEAD 2>/dev/null || true

printf '%s\n' '== /assign implementation references =='
rg -n -i -C 3 '/assign|auto-assigned|stale cleanup|unassign.*stale' \
  -g '*.yml' -g '*.yaml' -g '*.sh' -g 'assign-workflow.test.js' . \
  -g '!node_modules/**' -g '!dist/**' -g '!build/**' || true

printf '%s\n' '== Contract test =='
test_file="$(fd -a '^assign-workflow\.test\.js$' scripts/tests | head -n 1)"
if [ -n "$test_file" ]; then
  nl -ba "$test_file"
fi

#!/bin/bash
set -euo pipefail

for f in \
  .github/workflows/assign.yml \
  .github/workflows/assign-stale-cleanup.yml \
  .github/scripts/assign-issue.sh \
  .github/scripts/unassign-stale-issues.sh
do
  if [ -f "$f" ]; then
    printf '\n%s\n' "===== $f ====="
    awk '{ printf "%4d  %s\n", NR, $0 }' "$f"
  else
    printf '%s\n' "MISSING: $f"
  fi
done

@acoliver No—this cannot be done entirely in declarative GitHub Actions YAML.

YAML is appropriate for the triggers, exact-comment gate, permissions, concurrency, and scheduling. But the implementation also needs dynamic GitHub API work and control flow:

• query merged PRs, prior assignments, and open-assignment counts;
• find/update the sticky feedback comment;
• verify that GitHub actually applied an assignment;
• enumerate labeled issues and assignees;
• inspect assignment timestamps and linked PR activity;
• calculate the 14-day threshold, retry failed API calls, and loop over candidates.

Those require imperative code. The current checked-in shell scripts are a reasonable choice, particularly since the logic is independently contract-tested.

The alternative would be actions/github-script with embedded JavaScript/Octokit calls. That could remove the shell scripts (and likely checkout/chmod), but it would not be YAML-only—it would move the same complexity into inline JavaScript, which is generally less maintainable and harder to test than the present scripts.

@CodeRabbit is there an attack vector here and if so can we limit it? thinking like 1000 bots smash us with /assign ?

#!/bin/bash
set -euo pipefail

workflow="$(fd -a '^assign\.yml$' . -E node_modules -E dist -E build | head -n1)"
script="$(fd -a '^assign-issue\.sh$' . -E node_modules -E dist -E build | head -n1)"
test_file="$(fd -a '^assign-workflow\.test\.js$' . -E node_modules -E dist -E build | head -n1)"

printf '%s\n' '== Candidate paths =='
printf 'workflow=%s\nscript=%s\ntest=%s\n' "$workflow" "$script" "$test_file"

for file in "$workflow" "$script" "$test_file"; do
  if [ -n "$file" ] && [ -f "$file" ]; then
    printf '\n===== %s =====\n' "$file"
    nl -ba "$file"
  fi
done

#!/bin/bash
set -euo pipefail

find . \
  -path '*/node_modules' -prune -o \
  -path '*/dist' -prune -o \
  -path '*/build' -prune -o \
  -type f \( \
    -name 'assign.yml' -o \
    -name 'assign-issue.sh' -o \
    -name 'assign-workflow.test.js' \
  \) -print |
while IFS= read -r file; do
  printf '\n===== %s =====\n' "$file"
  sed -n '=' "$file" | sed 'N;s/\n/\t/'
done

#!/bin/bash
set -euo pipefail

for file in \
  .github/workflows/assign.yml \
  .github/scripts/assign-issue.sh \
  scripts/tests/assign-workflow.test.js
do
  if [ -f "$file" ]; then
    printf '\n===== %s =====\n' "$file"
    sed -n '1,260p' "$file"
  else
    printf 'MISSING: %s\n' "$file"
  fi
done

@acoliver Yes. The permission boundary is reasonably narrow—an untrusted bot cannot gain repository write access or bypass GitHub’s assignee rules—but there is a workflow/API-consumption denial-of-service vector:

• Every exact /assign issue comment starts a runner.
• The script checks out the repository, performs several gh API/search requests, and may update the sticky feedback comment before rejecting an ineligible account.
• The current concurrency key is per issue, so it coalesces spam on one issue, but 1,000 bots commenting on 1,000 issues can still create up to 1,000 jobs.

I would limit this in two layers:

1. Repository-wide concurrency for this workflow, rather than per-issue concurrency. This creates a hard upper bound on active/pending /assign work and lets GitHub discard superseded queued spam. The tradeoff is that legitimate assignment requests may need to be reposted if a burst occurs.

   concurrency:
     group: ${{ github.workflow }}
     cancel-in-progress: false

2. Fail closed as early as possible: add a job-level gate for repository-associated users where compatible with the intended policy, then keep the script’s authoritative eligibility checks. At minimum, put the cheap AUTHOR_ASSOCIATION check before the current assignment-count and search queries. Right now an unknown account consumes several API calls before it is denied.

Also, for failed eligibility, I would avoid posting/updating sticky feedback for every request—or only provide that feedback for known contributors. Otherwise attackers can deliberately generate persistent issue-comment noise and write API traffic.

The three-assignment cap protects issue ownership; it does not rate-limit invocation volume. I recommend treating global concurrency plus early rejection as required hardening before enabling this on a public repository.

@Ayush7614 look at #2634 (comment) and the other coderabbit reviews. LLet's assume at some point someone will comment /assign on everything so let's add a cap for how many issues they can be assigned at once, the concurrency cap. ask your agent for any other hardening recommendations to prevent also spammers (github name BuyMyStupidThing /assign every issue it can)

@acoliver addressed shellcheck + the spam-hardening notes (and CodeRabbit’s actionable items):

CI / shellcheck

• Fixed SC2154 / SC2269 / SC2249 locally with shellcheck 0.11.0 (same flags as CI).

Spam / flood hardening

• Hard 3 open-issue concurrency cap (already present; kept + documented more clearly).
• Workflow now ignores Bot accounts.
• Concurrency group is now per issue + actor, so a flood of /assign from one user cancels/queues on itself instead of fan-outing.
• Eligibility still requires merged PR / prior assignment / trusted list / owner-member-collaborator before assign.
• Non-collaborators still fail the post-assign verify and get sticky feedback (no silent “success”).

CodeRabbit

• Added pull-requests: read so gh search prs --merged works under the explicit permissions block.
• Stale cleanup now exempts only acoliver as an assignee (other co-assignees can still be unassigned).
• Dropped the 50-PR list fallback; linked-PR detection uses search only.

Happy to add more rate-limiting (e.g. daily attempt budget) if you want that next.